Automate the Dart/Flutter release for livekit-uniffi - #1323

Split the dart-package flow by cargo-make profile: dev builds keep the
embedded host dylib and publish_to: none, release builds omit the dylib
(consumers use the hook's download mode) and clear publish_to so pub.dev
accepts the package. The publish_to guard fails closed, an unknown
profile still renders none. A dart-clean task starts every build from
scratch so a release build over a previous dev tree cannot ship the
stale host dylib, which the hook would prefer over download on every
platform.

Also add the metadata pub.dev requires or scores: LICENSE, README,
CHANGELOG, repository/homepage/issue_tracker pubspec fields, real
version constraints for code_assets/hooks (wide ranges, flutter_test
pins meta exactly so carets break older stable channels), and an
analysis_options.yaml so unused-import lints in generated code do not
fail publish validation.

Verified: both profiles build, all 5 FFI tests pass on the dev package,
dart pub publish --dry-run exits 0 on the release package, and a
release build over a dev tree contains no dylib.

pub.dev's automated publishing only accepts workflows triggered by a
push of a tag matching the configured pattern, so this cannot be a job
in the release-event-triggered uniffi-packages.yml. The workflow builds
the release-profile package (cached, before the asset wait), stages it
outside the work tree (pub archives from git's file listing and the
generated packages/ tree is gitignored), refuses to publish a package
containing a local native library, gates on every cdylib zip having its
sha256 sidecar, and fast-fails on mis-pointed tags or a missing release.
Tag names are env-bound, never template-expanded into scripts, since
the job holds id-token: write for pub.dev token minting.

PUBLISHING IS NOT ENABLED YET (PUBLISH_ENABLED=false): every run stops
at dart pub publish --dry-run until the uniffi-dart pin moves off the
personal fork, a livekit.io publisher admin has done the first manual
publish, and automated publishing is configured on pub.dev. See the
header for the full enablement steps.

…elease

# Conflicts:
#	livekit-uniffi/Cargo.toml

The Swift and Android reusable workflows already build from
inputs.tag_name. Without it, a manual re-run of the cdylib job for an
older release built whatever ref the dispatch UI selected and uploaded
the result under that release's version with --clobber.

Native builds on ubuntu-latest inherit its glibc 2.39 floor, so the
published .so would fail to load on Debian 12, Ubuntu 22.04 and Amazon
Linux 2023, which is where server-side Dart consumers of the access token
API run. Build inside quay.io/pypa/manylinux_2_28 images instead, the
same approach ffi-builds.yml uses for livekit-ffi. The arm64 target now
runs on a native arm64 runner, which removes the cross-linker setup.

Action metadata formally requires one and actionlint flags every
workflow referencing the action without it. Cosmetic, GitHub runs the
action fine either way.

Each of the three Android matrix jobs compiled cargo-ndk from source on
every run, roughly 3-5 minutes per job on the release critical path.
taiki-e/install-action fetches the prebuilt binary in seconds, matching
how the repo installs cargo-make in the uniffi-deps action.

The publish job used to poll the release for up to 90 minutes waiting for
the cdylib job in uniffi-packages.yml to attach its assets, because
pub.dev only accepts publishes from a tag-push workflow while the assets
came from the release-event workflow. Call the reusable cdylib workflow
from the tag-push workflow instead and make the publish job depend on
it, so assets and package are produced by the same run and there is
nothing to poll. uniffi-packages.yml goes back to Swift and Android only.

The tag/crate version check moves to the resolve-tag job with a sparse
checkout, so a mis-pointed tag still fails before the build matrix
starts. A dry_run input skips the asset upload for exercising the
workflow by hand. Also drops the completed fork-pin enablement step from
the header.

A floating stable channel could pick up a new analyzer lint the week of
a release and fail the publish dry run, which treats any analyzer finding
as a warning. Pin both workflows to the same version so PR CI validates
what the publish will run with, and bump them together.